feat: expose evaluated scenario state on scenario binary_sensors - #171

I think this needs a config switch, globally, perhaps per scenario, since it has potential to increase compute a lot, including some folk running this on a tiny SBC

I had thought that scenario should be broken out to a separate plugin, since the idea of switchable fragments of config could be more useful, but its a lot of work to pull apart, especially if no concrete second case (though maybe I'm overlooking my own AutoArm). Having scenarios be properly event driven, reactive scenarios, would be sort of thing that plugin would be good at

Fair concern, and it turns out the numbers back it — but they point at the fan-out before the switch.

I benchmarked the refresh on the PR branch (Python 3.13, desktop CPU, 20 runs averaged), evaluating every scenario in the registry the way async_refresh_scenario_states does:

So the cost is driven by what the conditions do, not by how many scenarios there are: a 20x spread between simple conditions and the kind of template people actually write for "any window open" or a DND window. On an SBC that is a few hundred milliseconds, and that is per refresh.

Which is the real problem: the refresh currently re-evaluates every scenario on every state change of any watched entity. One motion sensor flipping re-runs all 25. The mapping needed to avoid that is already built in this PR — _collect_scenario_condition_entities() gives entity → scenarios — it just isn't used for dispatch. Evaluating only the scenarios that depend on the entity that changed turns the common case from "all of them" into "one or two", which is a bigger win than any flag, and it makes the 60-second sweep the only place where everything is evaluated together.

That, and the switch you asked for, are now pushed onto this branch:

• a state change now re-evaluates only the scenarios that depend on the entity that changed, using the index the PR was already building for its subscriptions;
• scenario_state: {enabled: false} subscribes to nothing and starts no timer — states stay STATE_UNKNOWN exactly as today, so nothing is paid by anyone who doesn't want the feature;
• scenario_state: {refresh_interval: <seconds>} tunes the sweep, since 60 s was a guess — someone on a Pi Zero may want 300, and 0 keeps the reactive path with no sweep at all;
• expose_state: false on an individual scenario keeps one expensive template out of it without turning the whole thing off.

Seven new tests cover the dispatch and the switch, including that an unrelated entity changing evaluates nothing at all. Full suite 1047 passing, ruff check, ruff format --check and mypy clean on Python 3.13, and the docs page has the new options.

I put the global option in CONFIG_ENTRY_SCHEMA, next to housekeeping and dupe_check, since it is runtime behaviour rather than notification config — say the word if you would rather have it in the YAML supernotify: block and I will move it.

On the plugin idea: worth saying that the entity extraction in this PR is the same thing reactive scenarios would need — knowing which entities a scenario actually depends on is the prerequisite for waking it on an event instead of sweeping it on a timer. So even if scenarios do get pulled out later, that part isn't wasted work.

If any of the naming or the defaults isn't what you had in mind, it is all in one commit and easy to reshape.